Schedule-Aware Transactions for Ambient Intelligence Environments

In this paper, the authors investigate the concept of designing user-centric transaction protocols toward achieving dependable coordination in AmI environments. As a proof-of-concept, this paper presents a protocol that takes into account the schedules of roaming users, which move from one AmI environment to another, avoiding abnormal termination of transactions when users leave an environment for a short time and return later. The authors compare the proposed schedule-aware protocol against a schedule-agnostic one. Findings show that the use of user-centric information in such situations is quite beneficial. Schuurmans, 2003; Weber et al., 2003). AmI is based on Weiser’s pioneer work on ubiquitous computing (Weiser, 1991), which evolved later on to the concept of pervasive computing. Pervasive computing aims at a digital world, consisting of interconnected electronic devices that support the quotidian activities of people. AmI is particularly concerned by the users’ experience in such a digital world. In other words, AmI puts a specific focus on the users and targets the development of user-centric digital environments that account for the users’ needs, habits and satisfaction, while offering support that allows them to perform their everyday activities. DOI: 10.4018/jaci.2010100106 72 International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. The vision of AmI motivates research towards coordination protocols that involve both mobile and fixed entities. In this paper, we particularly investigate the need for designing user-centric transaction protocols to achieve dependable coordination in AmI environments. User-centric information can be exploited while coordinating a set of transaction participants towards avoiding abnormal transaction terminations. In this context, we focus on the abnormal ending of a transaction that takes place within an AmI environment, due to the fact that one or more participating users leave the environment. Leaving the environment means that the users’ devices are no longer reachable, via the networking infrastructure that supports the transaction coordination. The idea behind our approach is that if there is a certain level of knowledge behind the schedule of each participating user (i.e., the way the user moves from one environment to another), then we can exploit it to avoid abnormal transaction terminations, where a roaming user leaves the environment for short, only to return later. Taking a simple example, consider a conference that takes place in a number of conference rooms. Several researchers attend a technical session in conference room A (i.e., environment A). In this situation, a number of colleagues want to arrange a meeting for dinner or work after the technical session. One of them browses, using his Pocket-PC, information regarding available meeting places. His goal is to book a place at a certain time and insert a dinner meeting in the agenda applications that execute on his colleagues’ laptops or Pocket-PCs. Obviously, setting up the dinner meeting involves performing a distributed transaction amongst the mobile devices that host the agenda applications. The transaction requires each participant’s agenda application to execute a local transaction and verify that there are no other obligations of the participant at the meeting time. This task might take a certain amount of time to complete. Assume now that during this time period, one of the participants leaves the gathering before the transaction completes, because his talk starts at conference room B (i.e., environment B). In such a situation, typical transaction protocols would abort the transaction, wasting thus the energy resources that were spent up to this point. Nevertheless, the transaction may have a chance for successful completion if we consider that the colleagues shall reunite after the coffee break. Hence, if the transaction protocol could be enriched with such kind of user-centric information (i.e., the users schedules) and reason with respect to this information, all the work that has been performed for fixing the dinner meeting would not be wasted. Based on the previous discussion, the contribution of this paper consists of designing a schedule-aware protocol and comparing it against a schedule-agnostic one. Specifically, in Section 2 we present the necessary background and state-of-the art for this paper. In Section 3 we detail the proposed protocol. In Section 4, we present our experimental results. Finally, in Section 5 we summarize our contribution and provide insights for future work. 1. RELATED WORK AND BACKGROUND The overall idea of user-centric transaction protocols and the particular protocol discussed in this paper fall in the general field of mobile transactions (Pitoura & Samaras, 1998; SeranoAlvarado, Roncancio, & Adiba, 2004). Until now there have been various approaches for mobile transactions that can be classified with respect to the system model that they assume into 3 different categories (Serano-Alvarado et al., 2004). In all of them the transaction initiator is a mobile host and the entities that comprise the data, processed during the transaction execution are fixed hosts. Moreover, Serano-Alvarado et al. (2004) further identified the following more generic execution models: 1. In the first system model, transactions are initiated by mobile hosts and they aim at processing data located on other mobile hosts. International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 73 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 2. The second system model is the most generic one, where the execution of mobile transactions is distributed amongst several mobile and fixed hosts. A few years ago, the previous execution models were considered as too ambitious but interesting (Serano-Alvarado et al., 2004). Nowadays, these models fit perfectly to the case of AmI environments. Until now, some interesting approaches have been proposed for dealing with transactions in the context of the aforementioned execution models. For instance, Bobineau, Pucheral, and Abdallah (2000), proposed a one-phase commit protocol for transactions involving mobile and fixed hosts, where the voting phase is eliminated and the master announces its own decision to the transaction participants; the decision is taken based on the master’s perception on the successful execution of the individual transaction steps. Kumar, Prabhu, Dunham, and Seydim (2002), proposed TCOT where the master employs timeouts towards deciding about the outcome of a particular transaction. Younas, Chao, Wang, and Huang (2007) dealt with mobile host disconnections in transactions that involve several mobile and fixed hosts by a protocol that discovers alternative mobile hosts that may replace the disconnected ones. Nouali, Doucet, and Drias (2005) proposed a protocol for transactions that span across several mobile hosts, which may move across different interconnected network cells. The main idea is to use participant-agents (i.e. proxies to participants that move to different network cells) to provide relocation transparency and timeouts to handle participant disconnections. Alternatively, Le and Nygard (2005) proposed the use of a data sharing space. Finally, Böttcher, Gruenwald, and Obermeier (2006) discuss a protocol that aims at reducing aborts and blocking time. In this paper, we go one step further by investigating the issue of using user-centric information towards designing distributed transaction protocols for AmI environments. The protocol that we investigate in this paper relies on the combination of two classical protocols: (a) the presume-abort 2-phase-commit protocol (Mohan, Lindsay, & Obermark, 1986) and (b) the strict 2-phase-locking protocol (Eswaran, Gray, Lorie, & Traiger, 1976). In general, the execution of a transaction involves (1) an entity that initiates it (hereafter we use the term master to refer to the transaction initiator) and (2) entities that comprise data, processed during the transaction execution (hereafter we use the term cohort to refer to these entities). Typically, the transaction execution consists of an initiation state, during which the master invites the cohorts to participate in the transaction and the cohorts accept or deny the invitation. If all goes well, the initiation state is followed by an executing state, during which the master processes data that may be of his own, or of the participating cohorts. At the time when the master decides to complete the transaction, the presume-abort protocol takes place amongst the participants (see Figure 1). Briefly, the presume-abort protocol comprises the two phases of the classical 2-phase-commit protocol. During the first phase, the master of the transaction sends to all cohorts a PREPARE message. Upon the reception of this message the cohorts should respond with their votes concerning the outcome of the transaction. The voting messages may be either to commit or to abort the transaction. After the voting the transaction gets into a prepared state and the cohorts wait for the final decision for the outcome of the transaction. The second phase of the protocol starts after the reception of all votes sent by the cohorts. If a negative vote exists, the master decides to abort the transaction, notifies accordingly all cohorts, and releases all information concerning the transaction (i.e., the transaction gets into an aborting/aborted state). Otherwise, if all votes were positive the master decides to commit the transaction, notifies accordingly all cohorts and waits for their acknowledgment (the transaction gets into a committing state). Upon the reception 74 International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. of the acknowledgments, the master releases all information concerning the transaction and the transaction get into a committed state. The presume-abort protocol further conforms to the following basic principle: if a transaction participant tries to find out about whether a transaction was finally committed or aborted and there is no information available about this transaction, the transaction participant derives the conclusion that the transaction was aborted. The strict 2-phase-locking protocol that we assume is a variant of the classical 2-phaselocking protocol, whose fundamental principle states that no locks can be released until all necessary locks have been acquired from the transaction. In the strict 2-phase-locking variant, all locks are released at the end of the transaction. 2. A SCHEDULE-AWARE PROTOCOL FOR AMI ENVIRONMENTS In this section we discuss the issue of usercentric transactions in the context of AmI environments. The problem we wish to handle concerns the abnormal ending of the transaction due to the fact that a mobile user / transaction participant leaves the AmI environment where the transaction takes place. The idea behind our approach is that if there is a certain level of knowledge behind the schedule of the user, then we can exploit it to avoid the abnormal transaction termination. Based on this idea, we present a schedule-aware transaction protocol. Before presenting the protocol’s internals, in Section 3.1, we start with preliminary concepts, foundations and assumptions for our problem. Figure 1. State diagram for a master completing a transaction under the a 2-phase commit protocol International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 75 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 2.1 Preliminaries In this section we provide a formal definition of the entities that participate in the AmI environment, along with any assumptions made for the purpose of this paper. In our modeling, an AmI environment is a set of cooperating nodes N. We deal with AmI environments as logical-level constructs that group nodes in a workgroup where they cooperate towards achieving a common goal. Depending on the case, this workgroup can be mapped to physical-level facilities (e.g., the AmI environment can be defined with respect to an area bounded by the connectivity range of a conventional networking infrastructure --e.g., a typical IEEE 802.11 network). More nodes can later join the environment and existing nodes can leave the environment. In the context of this paper, the terms ‘join’ and ‘leave’ the environment refer to a logical level participation to the AmI environment and not a physical one; in fact, the particularities of these actions at the physical level are orthogonal to the proposed protocol. Our overall system model consists of a set of distinct AmI environments. Communication between nodes of Ni, Nj, for all i, j | i ≠ j is not possible. The formation of the workgroup can be done by gathering the mobile nodes around a static, fixed point of reference (e.g., a standard access point in a building), or by arranging an ad-hoc network of mobile peers. In both of these cases, two kinds of nodes participate: (a) fixed nodes that are constantly part of their environment and (b) mobile nodes, corresponding to users that move over the set of AmI environments. At any given time point, each environment comprises its fixed nodes and a (possibly empty) set of mobile nodes that happen to be part of the environment at that moment. Each node n has (a) a unique node id and (b) a finite set of records, or variables, denoted as var(n), which are either read or updated in the context of a (possibly distributed) transaction. Moreover, each mobile node is characterized by a schedule that specifies its movement from one environment to another. A node’s schedule is a finite list of pairs of the form (environment, duration) characterizing how long the node will remain in each environment. In Figure 2, we depict he schedule of a node which is going to stay for 20 time points in environment N1, then move to environment N2 where it will remain for 30 time points, then return to environment N1 for a duration of 40 time points and finally move to environment N3 where it will stay for 44 time points. All nodes issue flat distributed transactions, i.e., transactions composed of tasks that are executed at different nodes, with the extra assumption that each node who is requested to perform such a task can execute this task locally without issuing another (nested) transaction. Also, we assume that each transaction is executed within the context of a single environment (still, this particular assumption can be relaxed with straightforward enhancements in the proposed protocol.). Formally, each transaction is defined as the following tuple: T = (TID, NID, MID, {Steps}) where TID is a unique identifier for the transaction, NID is the identifier of the environment within which the transaction must be executed, MID is the node identifier for the master node of the transaction and Steps is a finite list of steps (to be defined right away). Each Step is defined as a set of actions, with each action being a request to read or write a cohort’s variable. An action is, thus, defined as the following tuple: A = (CID, Action, Variable) where CID is the node identifier of the cohort node that executes the action, Action belonging to the set {READ, WRITE} and Variable being the variable being read or written. For reasons that will be apparent in the sequel, we would like to point out that it is easy to infer whether a node is mobile or fixed by its node id. 76 International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. 2.2 The Freeze on Leave Protocol The main thrust of our contribution lies in the exploitation of the schedules of the mobile nodes. Assume that a mobile node is about to leave an environment where it participates as a cohort to a distributed transaction. In this case, a typical transaction protocol would simply abort the transaction. Following a different direction, we build on the idea on requiring the node to notify the transaction’s master on its intention to leave, instead of sending an abort message. The crux of the proposed protocol is that the master tries to find a rendezvous, i.e., a time point and a subsequent interval where all the participants of the transaction will meet again in the same environment. If this is feasible, then the transaction is frozen, its state is recorded at the master and it will be de-frozen again when the master’s clock reaches the starting point of the rendezvous that the master has calculated. Due to this mechanism, we call this protocol Freeze on Leave (FOL). Assume a transaction that takes place in environment N1 and involves a fixed master and two mobile cohorts, m1 and m2. Assume that at time point τ the master receives a message from cohort m1 that the latter is leaving environment N1. The schedules of the two cohorts at time point τ are depicted in Figure 3. The master, can calculate that, according to the cohorts’ schedules, cohort m1 will be back at the environment N1 for the time interval [51-90] and cohort m2 will also be back for the time interval [71-90]. The overlap of the two schedules can serve as a “rescue” interval for the successful completion of the transaction. Interestingly, the protocol does not guarantee successful completion of the transaction. The risks of failure are primarily two: (a) a cohort violates its schedule and misses the rendezvous for the frozen transaction’s defreeze, or (b) the transaction cannot be completed in the common time interval of the cohorts. In both of the aforementioned cases the protocol guarantees that the transaction shall be aborted. In the rest of this section, we organize the discussion of the internals of the Freeze on Leave protocol in two parts: first we assume that the master is fixed and following we examine the case where the master is mobile. In both cases, the reaction of the master is also dependent upon the state in which it is in. If the master of the transaction is fixed, then it does not need to worry about its own schedule, since it will continuously be present at the environment where the transaction takes place. As already mentioned, we are particularly interested in the case where a mobile cohort sends a message LEAVE to the master, signifying the cohort’s intention to leave the environment. Whenever the master receives such a message it checks its state. If the master is in any state before executing, then it assumes that no work has actually been done (and therefore worth saving) and aborts the transaction. On the other hand, if the master is in an executing or prepared state, it understands that there is a chance of salvaging the work that has been performed so far. The actions of the master depend upon its state. Figure 2. Exemplary schedule of a mobile node International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 77 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. A cohort leaves and the master is in executing state: In this case, when the master receives the LEAVE message from the cohort, it initiates the procedure for finding a rendezvous, i.e., a common time point and a subsequent interval where all the mobile cohorts will be back in the environment again. In case there is no such interval, the transaction is aborted as usually. If, on the other hand, such an interval exists, the master proceeds as following: − First, the master checks whether there are steps that can be executed without the leaving cohort. If the next step requires the departing cohort, then the master node proceeds as follows: − it notifies all cohorts about the rendezvous by sending to them a FREEZE message; − if the master has received acknowledgements from the last step (i.e., read or write actions), it assumes a hung up state – else it assumes an ack hung up state until all acknowledgements arrive; − If there are steps that can be executed without the departing cohort, then the master proceeds as follows: − it notifies the departing cohort about the rendezvous by sending to it a FREEZE message; − it assumes a temp executing state; − it waits for a step that requires the presence of an absent cohort to signal a FREEZE message to all the cohorts and moves to a state of hung up or ack hung up. At the same time, when a cohort receives a FREEZE message, it moves to a hung up state. The execution of the transaction continues interactively. Whenever a participating cohort returns to the environment, the master node tries to execute the next step of the transaction. If the execution of the next step is possible the master passes in a temp executing state and keeps up with the execution of the transaction until a step that requires a missing node; otherwise it remains in its previous state. The overall defreeze of the transaction takes place when the rendezvous point arrives. At this point, the master checks if every cohort is present. If the rendezvous is missed, the master aborts the transaction and notifies all cohorts that are present accordingly. The cohorts that missed the rendezvous are aware of this situation; when the rendezvous is missed each one of them considers the transaction aborted. Observe Figure 4 depicting the state diagram for the master in this case. The darker nodes correspond to the typical presume-abort 2-phase-commit protocol and the white nodes present the proposed extension. A cohort leaves and the master is in prepared state: If the master receives a LEAVE message when it is in prepared state, it also needs to check whether it is possible to find a rendezvous. If such a rendezvous can not be found the transaction is aborted. Otherwise, the master (a) sends a FREEZE message to the cohort leaving the environment and (b) assumes a vote Figure 3. Schedules for mobile nodes at the time of departure of m1 78 International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. hung up state, waiting for the remaining cohorts’ votes. When the master can reach a decision for the transaction, there are two cases: − If the transaction is to be aborted, the master notifies all cohorts that are present about the decision and assumes a partially abort state, until the rendezvous point. At this point, the master sends an ABORT message to the returning cohorts and moves to an aborted state. Note that some cohorts may miss the rendezvous. These cohorts can not be notified by the master about the outcome of the transaction. However, since they are aware of the missed rendezvous, they shall abort the transaction by themselves. − If the transaction is to be committed, the master moves to the partially commit state, until the rendezvous. At this point, the master checks if every cohort is present. If the rendezvous is missed, the master assumes an aborted state. As previously, the cohorts that missed the rendezvous abort the transaction by themselves. If the rendezvous is met by all cohorts the master assumes a committing state. Observe Figure 5 depicting the state diagram for the master in this case. The darker nodes correspond to the typical presume-abort 2-phase-commit protocol and the white nodes present the proposed extension. If the master of the transaction is mobile, the overall behavior of the protocol is quite similar with what has been discussed for the case where the master is fixed. Nevertheless, below we summarize the main differences that exist in the case of the mobile master: − Whenever the master tries to calculate a rendezvous, it takes into account its own schedule along with the schedules of the participating cohorts. − If the master has to leave the environment while being in the executing or in the prepared state, there is nothing particularly different from the case of a mobile cohort leaving the environment. Nevertheless, due to the fact that the master needs to Figure 4. State diagram for the master, when a cohort leaves and the master is in prepared state International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 79 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. organize its departure and calculate the rendezvous, the master arranges to send a LEAVE message to itself somewhat earlier than its departure. 2.3 Discussion: Risks and Opportunities of the FOL Protocol In this section we discuss possible risks and opportunities for improvement of the proposed protocol and explain some of our design choices. Security and Privacy. A clear concern for the proposed protocol has to do with the fact that the cohorts’ schedules must be released to the master resulting in a breach of privacy for the cohorts. We should make clear that the proposed protocol operates under the assumption that the master is trusted. If the master is not trusted by even one of the cohorts, then clearly, the transaction execution falls back to a schedule-agnostic mode. Also, it is not necessary to submit the full agenda of a cohort to the master; it is only sufficient to release a reasonably small subset of it for the context of a transaction. This can be achieved via a negotiation step during the handshake phase between the master and the cohorts. It is also possible to devise further optimizations, such as the anonymization of sensitive parts and the disclosure only of the case where the cohort will be back in the master’s environment. Exploring these posibilities is an issue orthogonal to the protocol per se, especially since all of them result in the identification (or not) of common interval during which all the cohorts will be present in the same environment. So, for simplicity, in our deliberations we assume the simplest case, where all the cohorts automatically release their agendas to the master. Concerning security, the transmission of the schedule to the master can be encrypted and even locally stored in an encrypted scheme; still, this Figure 5. State diagram for the master, when a cohort leaves and the master is in prepared state 80 International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. is a topic for the implementing middleware to resolve and falls outside the scope of the paper. Strictness of schedules. What happens if a node does not stick to its schedule? This is a realistic question that has to be answered by the protocol. There are mainly two cases: (i) Α cohort is late in its rendezvous. Ιn this case, the master initiates an abort message and the late cohort presumes by default that an abort will occur. A simple extension of the protocol can even give some extra time after the rendezvous as a buffering period for latecomers; in fact this buffering period can even be calculated at the determination of the rendezvous time point. Still, this is a simple engineering extension to the protocol without significant implications. (ii) A cohort is early in its rendezvous. This is no problem per se, if the cohort intends to stick to its previous schedule for the rest of its tasks. At the same time, this also presents an opportunity if all cohorts arrive early. It is possible to devise schemes to take this case into consideration; in our case we considered this to be a rare case and opted for a simpler protocol. Other possible directions involve the monitoring of cohorts progress with respect to their registered schedule and the adaptation of the rendezvous point. We believe that the protocol should stick to local scope principle, in the sense that each master should only be interested in what happens in its specialized purview without global coordination or monitoring back-stage activities. Still, it is possible that in specialized situations, this could be performed with significant gains of committed transactions –at the expense, of course, of simplicity. Opportunities for improvements. It is possible for the skeptical reader to raise questions related to the assumptions made in this paper. A simple example involves the role of environments in the whole setting: for example, if two different environments are close in terms of wireless transmission, or, if they have direct connection of their fixed nodes, is it possible to take advantage of this fact and improve the protocol? So far, we have assumed that an environment is an area within which the mobile nodes can communicate with each other, so, strictly speaking, as long as there is network connectivity among the involved nodes we should still consider that they are in the same environment. Still, it is possible to consider situations where an environment is bounded by geographical and connectivity constraints. Mesh networks, each employing a dedicated gateway node could possibly be considered in such a scenario and a cooperative scheme between them could be devised. We consider this opportunity as a topic for future research. A second possibility has to do with the mobility of the nodes. Improvements of the protocol could be explored for the case that the nodes move groupwise, in a ‘herd’ fashion (Musolesi & Mascolo, 2007) as well in cases of other mobility models derived based on real-world observations (e.g., Bittner, Raffel, & Scholz, 2005; Tian, Haehner, Becker, Stepanov, & Rothermel, 2002). In general, a restriction of our model is that the nodes must return to the initiating environment to complete the transaction. It is possible to think of schemes where the nodes complete the transaction in another environment. Nevertheless, adopting such an approach would require total, detailed knowledge of all the schedules (against the aforementioned comments for privacy issues) and the environments and would result in a global scope rendezvous protocol. For practical purposes of efficiency and simplicity, we believe that a local, or at best, a limited horizon scope must be adopted, in which the rendezvous International Journal of Ambient Computing and Intelligence, 2(4), 71-86, October-December 2010 81 Copyright © 2010, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. are considered without total knowledge of the network structure or the nodes’ schedules. In other words, there is a trade-off between network and schedule knowledge, protocol simplicity and speed vs. the percentage of committed transactions. This trade-off is a function of the extent of the horizon that should be considered and its intricacies suggest another topic for future research.